Make weight.
Keep your power.

A fighter weighs in every morning. The numbers are noisy — water, food, glycogen — and judging a cut on a single reading is both wrong and stressful. OnWeight's whole job is to interpret those weigh-ins: smooth them into a true trend, project that trend to weigh-in day, and tell the athlete in plain, corner-coach language whether they'll make weight safely and on time.

The intelligence is three layers, and everything else hangs off them:

The app is paywalled end-to-end — no free tier. First-run is one funnel with a single hinge, the paywall: before it, the job is to convert (prove value, earn the subscription); after it, to activate (get the first weigh-in logged fast). The product then lives in a daily loop, escalates into a fight-week lifecycle, and falls back to a no-deadline maintenance mode between camps.

The two files that are the source of truth

How the prototype encodes navigation

The prototype is a screen registry plus a tap-delegation layer — the clearest spec of intended navigation. Two structures matter:

• SCREENS — every screen, its type (flow = Next advances · tabbed = live tab bar · plain = back only) and its next/back targets.
• WIRE — per-screen rules [regex on the tapped element's text → destination]. Read this as the navigation table: it documents exactly where each control leads.

Demo toggles in the prototype chrome — pace (on / behind / off), sport and sex — drive the verdicts, branching and the cycle model so you can reach every fork.

Supporting references in this bundle

• Logic & Flows — the engine source-of-truth: every formula, the tracking cascade, camp states, per-sport rules. The single most important doc for the math.
• Spec · Component Specs · Foundations · Copy Rules — navigation/inventory, the shared component kit, design tokens, and the corner-coach voice + locked lexicon.
• Weight-Tracking Methodology · Chart Explorer · Rules Verification — the science for sign-off, every chart in the app, and each sport figure beside its governing-body source.
• Accessibility Pass · BFM Audit · Prototype Gaps — the a11y review, the UX-psychology critique with fixes, and how the prototype is wired + what isn't linked yet.

The full file list is in §20. A live screen browser is in §04.

The design is iOS-native in spirit. SwiftUI is the recommended target. Recreate the UI pixel-faithfully using native components rather than reproducing the prototype's bespoke chrome:

The product breaks into the flows below. Screen ids match the prototype jump menu and the live browser further down. Open All Screens for pixel detail on any of them.

The flows

Key screens at a glance

A curated set — the heroes of each flow. The complete set is in the live browser below and in All Screens.

Live screen browser

Every screen, rendered live from the same components as All Screens. Pick one to load it in the device; scroll inside the device for the full screen.

Navigation & gestures

• Push for drill-downs, with one labelled back control and edge-swipe on every pushed screen.
• Detented bottom sheets (grabber + swipe-to-dismiss) for scoped tasks: confirms, pickers, log weight, info sheets.
• Alert / action sheet for destructive confirms, with a real red destructive role — never a fake "hold to confirm".
• Live tab bar (5 items) on the core tabbed screens: Today · Plan · Trend · Learn · More.

Controls are live and must reflect downstream

Toggles flip, segmented controls and radios move, multi-selects toggle. Critically: anywhere copy says targets or the trend "adjust on the spot", the change must re-run the projection and reflect everywhere. The plan editors already preview a before→after; the build must persist and recompute.

Verdict, transitions, motion

• Verdict logic: trend = EWMA of daily weigh-ins; pace verdict from the 7-day rolling rate + cycle-adjusted projection; drift-watch (CUSUM) is the early, non-red tier. Formulas in §07.
• Transitions: ~0.26s screen swap; respect prefers-reduced-motion. Entrance animations gate on the active state + reduced-motion so print/PDF/reduced-motion show content, never a pre-animation blank.
• Loading as labour: "Building your camp" animates the projection forming — keep it; it's the engineered beat before the paywall.

Per-user profile (set in onboarding, editable in Plan/Settings)

Daily & derived

• entries[]: { date, time, weight, note? } — one canonical fasted morning weigh-in per day; later same-day readings kept as context, never fed to the trend.
• Derived: trend (EWMA), 7-day velocity, projection cone, pace verdict, cycle offset/buffer, drift-watch CUSUM.

Camp state machine

// athlete-confirmed transitions — never silent
no-camp  ⇄  camp ( active → fightWeek → weighIn → made|missed
                   → rebuild → fightDay → result → recovery )  ⇄  paused

Full derivations and the evidence behind every default live in OnWeight - Logic & Flows. The essentials:

Trend (EWMA) & velocity

// 5-day exponentially-weighted moving average (the bold line; raw = faint dots)
trend[i] = Σ ( weight[i-k] · 0.75^k ) / Σ ( 0.75^k )   for k = 0..4
weeklyVelocity = 7-day change in the trend            // kg/week, negative = losing

Target weight (equipment changes the body target)

scaleTarget = divisionLimit                  // the official class limit
bodyTarget  = scaleTarget − equipmentWeight  // gear sports subtract gi/gear; underwear-only ≈ scaleTarget

Projection & the cycle-aware buffer

projected      = trendingToday + dailyVelocity × daysToWeighIn   // true-weight
weighInOffset  = cycleOffsetKg(weighInDay)     // kg the scale reads above true wt that day
projectedScale = projected + weighInOffset     // honest scale reading at weigh-in
cycleBuffer    = max(0, weighInOffset)         // extra TRUE weight to pre-cut
trueTarget     = bodyTarget − cycleBuffer
scaleGap       = projectedScale − bodyTarget   // the gap that decides made/missed

The Trend tab draws a projection cone — a widening fan whose upper edge carries the cycle-water risk — instead of an over-confident single line. Verdict: the cone clears / straddles / misses the limit.

Cut-rate thresholds (% bodyweight per week)

The verdict cascade (never judge a raw daily number)

1. Step 0 — Displayed trend: the only weight shown as a verdict is the 7-day-equivalent EWMA. Raw daily is logged and charted as dots, carries no verdict.
2. Step 1 — Daily silent gate: within ±200g of the cycle-adjusted expected weight → silently fine. Off it → escalate silently (no red).
3. Step 2 — 3-day provisional filter: 3-day average within ±0.4kg (≈0.5%, matched to its real noise) → treat as noise.
4. Step 3 — 7-day rate verdict: last-7-day vs prior-7-day true-weight rate (cycle-water removed) drives on-track / cutting-fast / behind. Needs ≥4 logs/window; <14 days → all-data regression.

Two-tier detection

Two independent re-plan triggers, both with hysteresis + a 2-reading confirm so the athlete is never bounced in and out of "off track": (A) projection miss — projected scale weight misses the limit across 2 readings; (B) safety ceiling — measured rate > 1%/wk regardless of whether weight will still be made.

Shown only when biologicalSex = female and the athlete opts in. The effect is small, fluid-only, and absent in many women — so the product leads with annotation over arithmetic.

The water-weight curve (one source of truth for every cycle chart + the projection)

cycleOffsetKg(day) = retention × −cos( 2π · (cycleDay − 10) / cycleLength )
// dips to −retention mid-follicular (~day 10), peaks +retention late luteal (~day 24)
// default amplitude retention = 0.5 kg · user-adjustable 0–2.5 · contraception/absent = 0

Three cycle modes

Learning (future-tier headline): once ~2–3 confirmed cycles are logged, fit each athlete's real luteal amplitude from the cyclic residual (detrend the cut first) and recommend an update — never silent, always overridable, labelled an estimate not medical advice.

The experience is bespoke per sport: weigh-in timing, equipment, re-weigh rule and the cut style all differ. Full sourced tables (men + women, every division) are in Logic & Flows §17 and cross-checked in Rules Verification. The shape:

Weigh-in timing sets the max safe fight-week water cut: same-day → ~0% (water cutting disabled, "walk-it-down"); within ~2h (BJJ) → minimal; day-before → up to ~5% of body mass, bounded by the re-weigh cap. Ship a per-sport division table; the athlete picks a division (autofills the scale target) — the typed limit is the fallback. The published division limit is the scale limit; gear sports subtract equipmentWeight to get the body target.

With no fight date, the countdown engine has nothing to anchor to. Maintenance mode replaces it with two date-free signals:

Anti-cycling is handled with gentle, educational nudges — never hard gates. Camp↔maintenance transitions are athlete-confirmed (prompted, flips only on confirmation) and carry over the walk-around baseline, division and learned-cycle data. Maintenance offers a "drop to weekly" weigh-in cadence.

Defined in fc-shared.jsx (THEMES.balanced). Full set + the cycle palette + WCAG figures are in Foundations. Every weight formats through a units engine (OWUnits) — never hard-code a unit string.

Colour

Typography

Shape, depth & metrics

Full states and anatomy are in Component Specs. The shared kit:

From the Accessibility Pass on the Balanced theme. The palette is genuinely accessible — the warm paper costs nothing on contrast.

A Built for Mars-style critique scored each flow against 8 psychology principles. Most findings have been rolled into the prototype, designs and docs; what you implement should preserve the fixes and honour the two systemic notes. Full record in OnWeight - BFM Audit.

What's strong (protect it)

• The verdict cascade — silent → silent → verdict, red only for real risk — is anxiety-reduction design at a rare level. Any reward/streak/social layer must never tip into comparison pressure or alarm.
• Goal-first onboarding, plan assembled during onboarding, the Coach's Read aha before price.
• Off-pace flow with hysteresis + two-read confirm and three safe outs (move division / move date / hold the safe rate).

Fixes applied

• Done Social proof moved earlier + onto the hinge — a distinct full-bleed proof band on the Coach's Read and paywall, grounded in real cited per-sport research (no fake user counts).
• Done 7-day free trial as the paywall's lifeboat, honestly framed ("we'll remind you 2 days before it ends").
• Done Division picker on the limit screen (keypad as fallback).
• Done First win before configuration — land on the dashboard empty state; precision setup is the opt-in "Sharpen" card.
• Done Habit-reward consistency strip on the post-log result; cycle "typical" number aligned to the 0.5kg default.

Two systemic notes to carry into the build

Still open (business/content, not design): final trial length + price; annual-only vs annual+monthly; replacing labelled placeholders (proof fighters/quotes, win-back & widget pricing) with verified content.

Every feature, categorised, split first-release versus future. needs a call marks an open product decision (see §18). Filter to scan.

These are designed as concepts (in fc-future.jsx) but are explicitly not in Release 1:

Also future-tier: weigh-in time-drift & week-vs-usual compare charts; cycle symptom logging, learned cycle model & forecast chart; all widgets.

1. Engine The cut-science engine — trend (EWMA), 7-day velocity, cycle offset/buffer, projection cone, pace tiers, drift-watch CUSUM, the verdict cascade and the two re-plan triggers (§07). Thresholds as configurable constants.
2. Live calc Live recalculation — Plan / Edit Plan / Sharpen / cycle changes must re-run the projection and reflect downstream. The editors already preview before→after.
3. Gestures Native gestures — edge-swipe back on pushed screens; swipe-to-dismiss + true detents on sheets.
4. Triggers Real-state triggers — billing state → subscription lifecycle; pace/drift math → verdicts & drift-watch; connectivity/purchase events → error states. (The ±20kg goal gate already fires on an unsafe typed target.)
5. OS Defer to the system — notification-permission and Health/Devices sync hand off to the OS Settings app, not duplicated in-app.
6. Data Persistence & data — persist every editor/picker selection and round-trip to the user record; the archive that pre-fills the next camp.
7. Units Units roll-through — wire OWUnits (kg↔lb) through every remaining screen; division tables canonical in source unit, convert at the edge, limits round down.
8. Re-engage Re-engagement lifecycle — reminder / email / win-back / "fight booked?" (load-bearing per §14).

The screen set is drafted across every journey. No area is "done" — everything is designed and awaiting review & approval. Treat sign-off as the minimum gate before build.

Designed — awaiting sign-off (11 areas)

Onboarding & entry · Core loop · Lifecycle states · Accounts & safety · Subscription lifecycle · Legal & data rights · Imperial (lb) parity · Per-sport copy parity · Notifications & sync · Widgets · Errors, empty & localization.

Open product decisions — needs a call

Content production

Learn library (needs written + medically-reviewed articles/video), Coach AI (needs scope + safety policy), Nutrition — all Future-tier (§16).

Open these first

• OnWeight - Developer Handover.html — this document.
• OnWeight - All Screens.html — full visual inventory (every screen).
• OnWeight - Prototype.html — wired interaction spec (tap through).
• fc-screen.html — single-screen renderer (?s=<id>); powers the live browser in §04.

Reference docs

• Logic & Flows — engine source-of-truth (formulas, cascade, per-sport rules).
• Spec · Component Specs · Foundations · Copy Rules — inventory, components, tokens, voice.
• Weight-Tracking Methodology · Chart Explorer · Rules Verification — science, charts, sport-rule sources.
• Feature List · Launch Readiness · Accessibility Pass · BFM Audit · Prototype Gaps — scope, status, a11y, UX critique, wiring notes.
• Onboarding & Goal-Setting · Camp Lifecycle · Daily Loop & Off-Pace — flow maps.
• Social Proof Research.md — sourcing for the proof band.

Component sources (spec reference — not for porting)

The .jsx files build the screens. Shared system is fc-shared.jsx; the engine is fc-engine.jsx; charts are fc-chart.jsx / fc-instruments.jsx; units are fc-units.jsx. The HTML files reference the JSX by filename and the JSX sits alongside them, so everything opens and runs as-is in a modern browser (in-browser Babel).